home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / infoham / 940234.txt < prev    next >
Internet Message Format  |  1994-06-04  |  26KB

  1. Date: Fri,  4 Mar 94 03:09:59 PST
  2. From: Info-Hams Mailing List and Newsgroup <info-hams@ucsd.edu>
  3. Errors-To: Info-Hams-Errors@UCSD.Edu
  4. Reply-To: Info-Hams@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Info-Hams Digest V94 #234
  7. To: Info-Hams
  8.  
  9.  
  10. Info-Hams Digest            Fri,  4 Mar 94       Volume 94 : Issue  234
  11.  
  12. Today's Topics:
  13.                ARRL DX Bulletin #12 - February 28, 1994
  14.                         Easy to get 6:1 balun?
  15.                       Errors in TNC2 firmware???
  16.                            FT-530 vs TH-78A
  17.                           Help!!! Please :)
  18.               Medium range point-to-point digital links
  19.                          Nude Radio Amateurs
  20.  
  21. Send Replies or notes for publication to: <Info-Hams@UCSD.Edu>
  22. Send subscription requests to: <Info-Hams-REQUEST@UCSD.Edu>
  23. Problems you can't solve otherwise to brian@ucsd.edu.
  24.  
  25. Archives of past issues of the Info-Hams Digest are available 
  26. (by FTP only) from UCSD.Edu in directory "mailarchives/info-hams".
  27.  
  28. We trust that readers are intelligent enough to realize that all text
  29. herein consists of personal comments and does not represent the official
  30. policies or positions of any party.  Your mileage may vary.  So there.
  31. ----------------------------------------------------------------------
  32.  
  33. Date: Wed, 2 Mar 1994 20:16:02 MST
  34. From: ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!nntp.cs.ubc.ca!alberta!ve6mgs!usenet@network.ucsd.edu
  35. Subject: ARRL DX Bulletin #12 - February 28, 1994
  36. To: info-hams@ucsd.edu
  37.  
  38. ZCZC AE10
  39. QST de W1AW  
  40. DX Bulletin 12  ARLD012
  41. >From ARRL Headquarters  
  42. Newington CT  February 28, 1994
  43. To all radio amateurs   
  44.  
  45. SB DX ARL ARLD012
  46. ARLD012 DX update
  47.  
  48. Documentation has been received and approved for the following
  49. operations:
  50.  
  51. Call: Operations Beginning (mm/dd/yy):
  52.  
  53. 3V8W           07/17/93  CW only 7, 14, 18, 21Mhz
  54. 7Q7JA          05/07/90 
  55. 8Q7BX          12/07/93
  56. 8R1/KD4GMV     01/11/94
  57. 8R1/KK4WW      01/11/94
  58. 9M2/DK7PE      05/17/93
  59. A35CW          01/06/94
  60. FS/W2QM        12/01/93
  61. H44/DK7PE      12/13/93
  62. HI8/7Q7JA      07/19/91
  63. P29VCW         05/18/93
  64. T7/DK7PE       05/10/93  144 Mhz 
  65. VK9MM          09/18/93
  66. V51/7Q7JA      07/18/91
  67. V63MV          12/23/92
  68. YJ0AXX         12/23/93
  69. ZD9SXW         09/29/93
  70. ZK1ACW         01/17/94
  71. ZV0ASN         01/01/94
  72. NNNN
  73.  
  74. --
  75. James J. Reisert  Internet:  reisert@wrksys.enet.dec.com
  76. Digital Equipment Corp.  UUCP:    ...decwrl!wrksys.enet.dec.com!reisert
  77. 146 Main Street - MLO3-6/C9 Voice:    508-493-5747
  78. Maynard, MA  01754  FAX:    508-493-0395
  79.  
  80. ------------------------------
  81.  
  82. Date: Thu, 3 Mar 1994 15:01:01 GMT
  83. From: netcomsv!netcomsv!bongo!julian@decwrl.dec.com
  84. Subject: Easy to get 6:1 balun?
  85. To: info-hams@ucsd.edu
  86.  
  87. In article <wier-020394203159@198.213.12.252> wier@merlin.etsu.edu (Bob Wier) writes:
  88. >Having a scanner with a 50 ohm input, I decided to try
  89. >a tv antenna (yagi) as a directional antenna. Small snag -
  90. >I got a 300 to 75 ohm transmormer, fed it to the 50
  91. >ohm input and it seemed to work reasonably well, but
  92. >I'd still like to get a better match. Does anyone know
  93. >where you can come up with a 300 ohm balanced to 50
  94. >ohm unbalanced (coax) transformer which would be good
  95. >up to about 1Ghz?  
  96.  
  97.  You are making a rash assumption that the input impedance of
  98. your scanner is 50 Ohms across its range. Trust me, it isn't. 
  99.  
  100.  If your antenna is not working optimally with your scanner,
  101. there are many things that could be wrong besides the balun and coax
  102. impedance. Loss in the balun at frequencies of interest may be one, so
  103. get the best TV/UHF balun you can find. The antenna may not be optimum
  104. at the frequencies of interest.
  105.  
  106.  Feeding your scanner with 75 Ohm coax won't make any
  107. difference that you will notice. Feeding it with a long run of cheesy
  108. coax will make a difference.
  109.  
  110.  Getting your antenna up high and in the clear will make a
  111. difference.
  112.  
  113.  
  114. -- 
  115. Julian Macassey, N6ARE  julian@bongo.tele.com Voice: (310) 659-3366
  116. Paper Mail: Apt 225, 975 Hancock Ave, West Hollywood, California 90069-4074
  117.  
  118. ------------------------------
  119.  
  120. Date: 28 Feb 94 06:25:08 GMT
  121. From: nprdc!ihnp4.ucsd.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!agate!library.ucla.edu!csulb.edu!tern.csulb.edu!usenet@network.ucsd.edu
  122. Subject: Errors in TNC2 firmware???
  123. To: info-hams@ucsd.edu
  124.  
  125.   I have recently been experimenting with TNC2 clones and had run
  126. across two peculiar "bugs" in the firmware of an MFJ 1278, and
  127. a tiny TNC2.  
  128.   
  129.   The first problem relates to when the TNC2 sends to the computer
  130. the "Change incoming stream" command ("|B" to switch to stream B, 
  131. for example).  It seems that when in command mode, the TNC set the 
  132. output stream to be equal to the input stream whenever it sends
  133. the "cmd:" prompt (if, of course. the output stream was set to
  134. something else previously).  So it you are in command mode in stream
  135. A, and send a "|b" to set the input stream to B, and press Enter,
  136. the tnc will respond with "|Bcmd:" to tell that the output stream
  137. should now ALSO be set to stream B.  The problem is this:  The stream
  138. switch is sent JUST before sending the cmd: prompt.  So if you are on
  139. stream A in command mode, and type "|bcst<CR>" to set the input to
  140. stream B and get the status of all streams, the tnc will send the
  141. results, THEN the |B, then the new cmd: prompt.  SO, the output of
  142. the cst  request made on stream B will be sent to stream A.  In fact,
  143. the results will show that the input stream is B, while the output
  144. stream is A!  Of course, if you type another "cst<CR>", the results
  145. will be sent to the proper stream, because it has already been
  146. corrected.  Do all TNC2's exhibit this feature?
  147.  
  148. The second problem is more major.  I seems that when I am connected
  149. on two streams, and send text out on the first stream, and then
  150. switch to the second and do nothing, all output from the tnc is
  151. halted.  For example, if I am connected on stream A and B to two
  152. bbs's, and I am currently on stream A, and I send "l<CR>|B" to list
  153. all files on the first bbs and then switch my input to the second
  154. bbs, the tnc will halt all output back to me.  The results of the
  155. list command will come back to the tnc, and the tnc will receive them
  156. all internally, but will not send them to the computer....UNTIL I
  157. sent something to the tnc first.  (Usually I send "^ck<CR>" to enter
  158. and then leave command mode.  This will then allow all buffered data
  159. to be sent to me.  However, it you do not send anything to the tnc,
  160. it will send nothing to you.
  161.  
  162. I have found these problems by using paKet 5.1.  PaKet creates
  163. a different window for each of the tnc's streams, and pressing a 
  164. shifted arrow key allows you to switch between the streams.  When you
  165. do this, paKet sends a "|" and the stream identifier.  Therefore, it
  166. is very easy to switch to another stream to view incoming data,
  167. without wanting to send anything, thus causing the second problem.  
  168. And having entering a command in one window and having the output
  169. return in another window (the first problem)  was also easily
  170. spotted.  I have reproduced these problems using a simple terminal,
  171. so they are not errors with paKet.
  172.  
  173. One other note.  I have also played with some Kantronics Tnc.  They
  174. do not appear to have the lockup problem, but have an even worse
  175. version of the first bug.  The incoming stream sent from the Kan TNC's
  176. is only changed when data comes in from over the air, not from
  177. commands.  So if I am on stream A, and switch to stream B, SEND a
  178. <CR>, (this would fix the TNC2 problem), and start sending commands,
  179. the tnc never send me the stream switch command, so all the feedback
  180. from my commands always goes to stream A, (or whatever the last
  181. stream to receive over the air was).  This is very frustrating when
  182. using paKet!
  183.  
  184. Anyone have any comments on any of this?  Has anyone else experienced
  185. this?  Any ideas for solutions?  
  186.  
  187.  
  188. -- 
  189. Byon Garrabrant  KD6BCH  byon@csulb.edu
  190.  
  191. ------------------------------
  192.  
  193. Date: 28 Feb 94 04:08:32 GMT
  194. From: nprdc!ihnp4.ucsd.edu!swrinde!cs.utexas.edu!howland.reston.ans.net!sol.ctr.columbia.edu!hamblin.math.byu.edu!yvax.byu.edu!sandersm@network.ucsd.edu
  195. Subject: FT-530 vs TH-78A
  196. To: info-hams@ucsd.edu
  197.  
  198. I am debating on wether to buy a Yaesu FT-530 or a Kenwood Th-78A. I would like  
  199. to hear experiences from owners of both radios. I am new to this hobby and
  200. would appreciate any info.  73's  TNX  Chad
  201.  
  202. ------------------------------
  203.  
  204. Date: 28 Feb 94 05:49:10 GMT
  205. From: nprdc!ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!elvis.umd.umich.edu!erik@network.ucsd.edu
  206. Subject: Help!!! Please :)
  207. To: info-hams@ucsd.edu
  208.  
  209. i Recently purchased a Kenwood r-5000 general coverage receiver.  This
  210. machine was used so I didn't get a manual....I've figured out everything
  211. except for probably the most obvious feature....I cannot figure out how
  212. to set the clock, go figure.  If anyone could give me at least a clue,
  213. it would be appreciated.
  214.  
  215.      Thanks and 73,
  216.  
  217.      EriK N8QLS 
  218.  
  219. ------------------------------
  220.  
  221. Date: Thu, 3 Mar 1994 15:34:56 GMT
  222. From: ihnp4.ucsd.edu!swrinde!gatech!wa4mei!ke4zv!gary@network.ucsd.edu
  223. Subject: Medium range point-to-point digital links
  224. To: info-hams@ucsd.edu
  225.  
  226. In article <CM1nqJ.MBx@srgenprp.sr.hp.com> glenne@sad.hp.com (Glenn Elmore) writes:
  227. [I wrote] 
  228. >> We're dealing with a very sparse matrix here. You don't seem to understand 
  229. >> that as you sit in a dense metroplex with hams on nearly every block. The 
  230. >> rest of the country just isn't like that. *Most* of our links are 60-80 miles
  231. >> long, over unfavorable terrain, to sites we can *get*. Nearly *none* of them 
  232. >> are LOS. We *depend* on the beyond LOS propagation available most easily at 
  233. >> lower frequencies to maintain those links. (If we could muster the power to 
  234. >> do microwave forward scatter, that would be different, but there just aren't 
  235. >> enough surplus TWTs out there to do the job, and site managers frown on 32 ft
  236. >> dishes on their towers. We *can't* depend on inversions and ducts, they just
  237. >> aren't reliable enough.)
  238. >
  239. >  At least you and I agree on the need for engineered, reliable links
  240. >and that construction of a network will take a great deal of
  241. >cooperation.  I've emphasized that one of the few strengths amateur networking
  242. >*may* have is "ins" and access to local sites.  All these are 
  243. >points I've tried to make in some of my CNC contributions.
  244.  
  245. Yes, but as you indicate below, the sites we *can* get aren't usually
  246. sufficient for a LOS network of national scope. I can't emphasize enough
  247. how *big* the vacant spaces are between groups of amateur packeteers in
  248. much of the country, or how unsuited to LOS paths much of the terrain
  249. separating them is.
  250.  
  251. >  And in case you think I'm in a densely populated, ideal terrain out here,
  252. >think again. Mountains only work for you when you can get access and have
  253. >helpers to maintain them (as you suggest). I end up spending a lot of my time
  254. >with a 3 arc-second elevation database trying to figure out how to make
  255. >a well connected network out of sparse users and large obstacles. My few
  256. >links are (too) long just as you say yours are there.
  257.  
  258. Yes, but, for example, there are more hams in LA metro than in all of
  259. Georgia. Other states are even less densely populated with amateurs
  260. and/or suitable high sites. This is a source of incredible frustration
  261. to a potential network designer.
  262.  
  263. >  My argument with your 56kbps approach is that it simply doesn't come
  264. >close to being enough capacity.  It isn't nearly adequate for the needs
  265. >of a competetive nationwide amateur network.  And, in addition,depending
  266. >on non-LOS propagation while maintaining reliability is an even less
  267. >optimum use of resources. 
  268.  
  269. The only reason I'm pushing 56 kb BLOS links is that I think they're closer
  270. to *possible* than microwave LOS links in many cases. I do *not* say
  271. we shouldn't use faster links where we can make them work. I just don't
  272. think that's going to be enough places to fill out the national network.
  273. I think we're going to have to use beyond LOS paths for a lot of the 
  274. links, just as we do now at 1200 and 9600 baud. If we can upgrade most
  275. of those to 56 kb, we'll have made a large improvement in the network
  276. capacity and capability. Now I know that doesn't fullfill your dream
  277. of a data superhighway, but just as we don't build interstates anymore
  278. because it's too costly to serve the remaining areas, I think we have
  279. to scale our network plans to the reality of paved two lane rural highways.
  280. That's still a big step up from the game trails and dirt ruts we're
  281. using now.
  282.  
  283. >  How do you intend to support even a fraction of the "20% of hams who call
  284. >packet their primary mode" with even *mediocre* performance (never mind
  285. >something competetive with telephone line modems which would stimulate and
  286. >support growth), 50 dB fade margins etc?
  287.  
  288. As the telcos know, most traffic is local. Out of LATA traffic is orders
  289. of magnitude less than what the local switches have to support. I'm talking
  290. about the out of LATA connectivity here. If a local area can support megabaud+
  291. local hubs, great, but for the vast expanses the national net has to cross,
  292. that's not viable. A 20:1 ratio of intra-LATA to inter-LATA capacity is
  293. reasonable.
  294.  
  295. >  You've presented some equations relative to non-quality paths, troposcatter
  296. >etc, could you show us how a system like that can provide the required
  297. >total information capacity and approximately what it might cost?  
  298.  
  299. I'll give a quick cost estimate, about $6 million in capital outlays 
  300. and a continuing site rental of around $1.5 million per year. That'll 
  301. buy us a 47X increase in speed, and a much higher increase in effective 
  302. throughput due to engineered duplex non-contending links, over what we 
  303. have now, and give us the full connectivity that we currently lack. Long 
  304. distance performance will be limited by the network delays and capacity 
  305. limits, but at least it will exist.
  306.  
  307. >  Could you present an estimation for us all of what the approximate vhf
  308. >hardware and resulting per-user capacity of a reliable nationwide
  309. >network of 3000 56 kbps full duplex nodes (your numbers) using beyond
  310. >LOS propagation might be?  Please show not only margins and hardware for
  311. >an individual link but also an estimate of the spacial and frequency reuse
  312. >problem/potential.
  313. >
  314. >  My estimates and opinion of the above indicate that it falls orders of
  315. >magnitude short of providing service adequate to support itself in an
  316. >amateur environment. I truly hope you can show me my error(s) and that a
  317. >beyond-LOS vhf network is viable. 
  318.  
  319. Well there is an existance proof that beyond LOS VHF networks are viable
  320. in the amateur community, *the existing 1200 baud networks*, and their site
  321. costs are on the same order as the proposed system. What I'm proposing is 
  322. a dramatic upgrading and expansion, at low UHF, of that system, but with 
  323. the careful engineering and organizational maintenance that the current 
  324. system lacks. No it won't carry long distance digitized voice or video, 
  325. much as I would like that to be true, nor will it allow remote interactive 
  326. logins on a coast to coast basis, but it will allow the movement of Email 
  327. and other bulk data transfers in a timely manner in a way that's completely 
  328. divorced from the commercial communications infrastructure. And higher speed 
  329. links in local areas, *where they are viable*, will allow some of those 
  330. advanced features. We just can't support that kind of bandwidth and response 
  331. time on a national basis. Too many sites, too much geography, too few hams.
  332.  
  333. Gary
  334. -- 
  335. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  336. Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
  337. 534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
  338. Lawrenceville, GA 30244     |                     | 
  339.  
  340. ------------------------------
  341.  
  342. Date: 3 Mar 94 15:17:27 -0800
  343. From: news.acns.nwu.edu!math.ohio-state.edu!sdd.hp.com!sgiblab!wrdis02.robins.af.mil!apollo.robins.af.mil!woodj@network.ucsd.edu
  344. Subject: Nude Radio Amateurs
  345. To: info-hams@ucsd.edu
  346.  
  347. In article <2kti7d$lai@transfer.stratus.com>,
  348. northup@hoop.sw.stratus.com (Bill Northup) writes:
  349. > julian@bongo.tele.com (Julian Macassey) writes:
  350. > : 
  351. > :  The Conservative radio amateurs always make sure they are
  352. > : properly attired before engaging in QSOs.
  353. > Does this mean that we have to start practicing safe QSOs ?
  354.  
  355. Should the prophylactic go over the speaker or the key/microphone??
  356. What about safe QSOs on packet!?  Cover the the CRT and keyboard???
  357. Maybe one big prophylactic covering the antenna would be a cure-all?
  358. The answer:  Abstinence.  Result:  Less band crowding. :^)  Jim KA4GHX
  359.  
  360. ------------------------------
  361.  
  362. Date: Thu, 3 Mar 1994 14:51:46 GMT
  363. From: netcomsv!netcomsv!bongo!julian@decwrl.dec.com
  364. To: info-hams@ucsd.edu
  365.  
  366. References <1994Mar2.144907.26098@bongo.tele.com>, <CM2960.93I@ucdavis.edu>, <2l3nuj$pr@bigfoot.wustl.edu>e
  367. Subject : Re: JARGON
  368.  
  369. In article <2l3nuj$pr@bigfoot.wustl.edu> jlw3@cec3.wustl.edu (Jesse L Wei) writes:
  370. >Now this is my question:  do hams *ever* talk about anything besides what
  371. >kind of rig (s)he's got, ham problems, ham equipment, etc?  
  372.  
  373.  I like to talk about drunkeness, debauchery, politics and
  374. current affairs. This may be the reason that no one ever talks to me
  375. on the Los Angeles repeaters.
  376.  
  377.  Mind you, when I do get technical and say things like "Your
  378. deviation is low", they offer to change their batteries. 
  379.  
  380.  
  381. -- 
  382. Julian Macassey, N6ARE  julian@bongo.tele.com Voice: (310) 659-3366
  383. Paper Mail: Apt 225, 975 Hancock Ave, West Hollywood, California 90069-4074
  384.  
  385. ------------------------------
  386.  
  387. Date: Thu, 3 Mar 1994 15:30:14 GMT
  388. From: news.acns.nwu.edu!math.ohio-state.edu!howland.reston.ans.net!gatech!swrinde!sgiblab!wetware!spunky.RedBrick.COM!psinntp!psinntp!arrl.org!zlau@network.ucsd.edu
  389. To: info-hams@ucsd.edu
  390.  
  391. References <1994Feb28.154040.17074@ke4zv.atl.ga.us>, <1994Feb28.212904.10734@arrl.org>, <1994Mar2.054202.25433@ke4zv.atl.ga.us>
  392. Subject : Re: Medium range point-to-point digital links
  393.  
  394. Gary Coffman (gary@ke4zv.atl.ga.us) wrote:
  395.  
  396. : Ah yes, DX Packetcluster. "Hey George, the link's flaky." 
  397. : "Well put up stacked beams and pile on the kilowatts,
  398. : to hell with the other digital users, the DX spots
  399. : have to get through."  (I've actually heard exchanges
  400. : like that. The lack of cooperation between the Packetcluster
  401. : operators and the rest of the digital community is somewhat
  402. : legendary. It's that Type A DXer mentality.)
  403.  
  404. Considering what Gary has written, I don't find the lack
  405. of cooperation a surprise.  Nor do I really think it to
  406. be a problem worth solving, due to the lack of excess
  407. capacity to be shared.  Actually, having a number of
  408. separate networks may actually be an advantage in an
  409. emergency, since the redundancy may help assure that
  410. something is still working after the disaster strikes.
  411. It might also be useful for seeing what actually works
  412. better in the real world.
  413.  
  414. BTW--how else does one improve a point to point link,
  415. besides using bigger antennas and more power?  The only
  416. solutions I can think of are changing frequencies or 
  417. adding sites.  Obviously, if there is an interference 
  418. problem, it is easier if the *other* guy were to move.  
  419. I don't think there is any disagreement that sites are 
  420. hard to find, which is why I say people should keep an 
  421. open mind and consider a variety of possibilities.
  422.  
  423.  
  424.  
  425.  
  426.  
  427. -- 
  428. Zack Lau  KH6CP/1           2 way QRP WAS
  429.                            8 States on 10 GHz
  430. Internet: zlau@arrl.org   10 grids on 2304 MHz
  431.  
  432. ------------------------------
  433.  
  434. Date: Thu, 3 Mar 1994 14:41:59 GMT
  435. From: ihnp4.ucsd.edu!sdd.hp.com!vixen.cso.uiuc.edu!howland.reston.ans.net!gatech!wa4mei!ke4zv!gary@network.ucsd.edu
  436. To: info-hams@ucsd.edu
  437.  
  438. References <gradyCLsKtB.I3r@netcom.com>, <kmeyer.3b0x@bbs.xnet.com>, <1994Mar2.175938.12119@alw.nih.gov>
  439. Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman)
  440. Subject : Re: Further criminalization of scanning
  441.  
  442. In article <1994Mar2.175938.12119@alw.nih.gov> weisen@alw.nih.gov (Neil Weisenfeld) writes:
  443. >Rather than thickening the law books, the government should educate the
  444. >public about what is going on.  The public will demand encrypted
  445. >cordless phones and the manufacturers will deliver.  Then the radio
  446. >voyeurs have more challenges to liven up the sport :-).  All the law is
  447. >going to do is damage the lives of the very few people who get caught and
  448. >damage the lives of the many who blab all sorts of confidential information
  449. >on their cordless phones.
  450. >
  451. >I'd be interested if other people agree.
  452.  
  453. I agree, both with the idea that government is too quick to say "there
  454. ought to be a law" and that scanner hobbiests are at heart voyeurs. That's
  455. where the basic difficulty arises. Laws against Peeping Toms have existed
  456. for centuries. Congress is trying to extend that principle into the wireless 
  457. age, but they're making the same mistake here as they are with the problem
  458. of violence in society. Banning scanners will be no more effective than
  459. banning guns, and has the undesirable side effect of causing unnecessary
  460. harm to legitimate users of these tools. The real problem in both cases
  461. is sick and twisted individuals with no sense of morals or ethics, not
  462. the hardware that enables them to pursue their voyeurism or violence.
  463.  
  464. Gary
  465. -- 
  466. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  467. Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
  468. 534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
  469. Lawrenceville, GA 30244     |                     | 
  470.  
  471. ------------------------------
  472.  
  473. Date: 3 Mar 94 14:59:41 GMT
  474. From: yuma!galen@purdue.edu
  475. To: info-hams@ucsd.edu
  476.  
  477. References <CLMqI7.Bvn@murdoch.acc.Virginia.EDU>, <9402271401591.gilbaronw0mn.DLITE@delphi.com>, <2l3360$4jr@news.acns.nwu.edu>
  478. Subject : Re: Electric Fence RFI/ Liabilities
  479.  
  480. >In article <9402271401591.gilbaronw0mn.DLITE@delphi.com>,
  481. >Gilbert Baron <gilbaronw0mn@delphi.com> wrote:
  482. >>>I've got some bad interference on 80 through 10
  483. >>>meter bands from an electric fence about 500
  484. >>>feet away. The effect is very sharp clicks
  485. >>>Anyone have any cures?
  486. >>>Ned Hamilton, AB6FI
  487. >>
  488. >>Well, if you ground the fence, case closed.
  489. >>                   Gil Baron, El Baron Rojo, W0MN Rochester,MN
  490.  
  491. If you disable an electric fence and the livestock gets out and causes
  492. damage or gets killed, you're in big trouble.  Those critters are expensive,
  493. and if someone hits one with a car...
  494.  
  495. If you can wait a few weeks until the grass starts to grow, the livestock
  496. will get a few zaps, learn about the fence, and I'll bet the owner shuts
  497. it off.
  498.  
  499. It also helps to make sure the fence has good grounds and no partial shorts
  500. to fence poles, the grass, etc.
  501.  
  502. Galen, KF0YJ
  503. I get E-fence I too.
  504.  
  505. ------------------------------
  506.  
  507. Date: Thu, 3 Mar 1994 19:55:12 GMT
  508. From: news.Hawaii.Edu!uhunix3.uhcc.Hawaii.Edu!jherman@ames.arpa
  509. To: info-hams@ucsd.edu
  510.  
  511. References <2k0eup$k3o@crcnis1.unl.edu>, <rcrw90-180294093408@waters.corp.mot.com.corp.mot.com>, <2kcdqj$nto@crcnis1.unl.edu>.uhcc.
  512. Subject : Re: Keyboards at testing sessions
  513.  
  514. In article <2kcdqj$nto@crcnis1.unl.edu> mcduffie@unlinfo.unl.edu (Gary McDuffie Sr) writes:
  515. >rcrw90@email.mot.com (Mike Waters) writes:
  516. >
  517. > >The need is not to show that someone *is* or *could* cheat, but for them to
  518. > >prove that they *could not* cheat..  If you want to use some piece of
  519. > >equipment in a testing session *you* must show that (a) you are not using
  520. > >it to cheat and (b) it won't disturb the other test takers.
  521. >
  522. >Oh, we are back to guilty_until_proven_innocent now? Be real!
  523.  
  524. Gary: I guess you mean to say `Be realistic' - not sure what `Be real' means.
  525. I believe Mike is being realistic - talk to some of the OT VEs about what
  526. some folks will do, in regards to cheating, in order to pass their test.
  527.  
  528. When I give a math exam I have to be quite vigilant in watching my 
  529. students; I've given quite a few Fs over the years to those I've caught
  530. cheating. The students who've spent many, many hours preparing for an exam 
  531. should not have to share their reward with someone who was irresponsible
  532. in their studies, whether it's a government radio exam or math exam.
  533.  
  534. 73,
  535. Jeff
  536.  
  537.  
  538. =============================================================================
  539. Jeffrey Herman NH6IL jherman@hawaii.edu, who, in his spare time, cannibalizes
  540. old TV sets to make QRPp transmitters (CW, of course).
  541.  
  542. Previously: WA6QIJ, WH6AEQ, NMO (U.S. Coast Guard Radio Honolulu: 500 kc CW)
  543.             NMC6 (U.S, Coast Guard Group Monterey)
  544.  
  545. Vietnamese Proverb: If you study you will become what you wish
  546.                     If you do not study you will never become anything.
  547. =============================================================================
  548.  
  549. ------------------------------
  550.  
  551. Date: Thu, 3 Mar 1994 19:10:07 GMT
  552. From: news.acns.nwu.edu!math.ohio-state.edu!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!sgiblab!sgigate.sgi.com!odin!chuck.dallas.sgi.com!adams@network.ucsd.edu
  553. To: info-hams@ucsd.edu
  554.  
  555. References <14@ted.win.net><CLwqAH.LHE@odin.corp.sgi.com>, <110@ted.win.net>, <CM3nI1.79r@odin.corp.sgi.com>
  556. Subject : Re: 40 meter QRP (cw or ssb)
  557.  
  558. In article <110@ted.win.net>, mjsilva@ted.win.net (Michael Silva) writes:
  559. ...stuff deleted...
  560. |> >World Record is 75.2 WPM.  It will not stand for much longer.
  561. ...more stuff deleted...
  562. |> Why won't it stand much longer?
  563. |> 
  564. |> 
  565. |> Mike, KK6GM
  566. |> 
  567. |> 
  568.  
  569. it should be broken by one or more people within the next year.
  570. my prediction.
  571.  
  572. dit dit
  573.  
  574. -- 
  575. Chuck Adams  K5FO  CP-60
  576. adams@sgi.com
  577.  
  578. ------------------------------
  579.  
  580. End of Info-Hams Digest V94 #234
  581. ******************************
  582. ******************************
  583.